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— The MAILING DATE of this communication appears on th cover sheet with th correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

• tf the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days wilt be considered timely. 

• If NO period for reply is specified above, the maximum statutory period will apply and wit) expire SIX (6) MONTHS from the mailing date of this communication. 

• Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 

• Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)E3 Responsive to communication(s) filed on 28 July 2003 . 
2a)|S This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Qway/e, 1935 CD. 1 1 , 453 O.G. 213. 
Disposition of Claims 

4) [S Claim(s) 1.2.4-7.9.11,12 and 14-20 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) E3 Claim(s) 1.2.4-7.9.11.12 and 14-20 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10) [3 The drawing(s) filed on 28 July 2003 is/are: a)S accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 

11) 133 The proposed drawing correction filed on'jj^J^is: a)KI approved b)D disapproved by the Examiner. 

If approved, corrected drawings are required in reply to this Office action. 

12) D The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C. §§119 and 1 20 

13) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 

aO All b)D Some*c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. D Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

14) D Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 119(e) (to a provisional application). 

a) □ The translation of the foreign language provisional application has been received. 

15) D Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121. 

Attachment(s) 

1) □ Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) Paper No(s). . 

2) CD Notice of Draftsperson's Patent Drawing Review (PTO-948) 5) [H Notice of Informal Patent Application (PTO-152) 

3) □ Information Disclosure Statement(s) (PTO-1449) Paper No(s) . 6) □ Other: 
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DETAILED ACTION 

1 . This action is in response to the amendment filed on 7/28/03. 

2. The objections to the drawings are withdrawn in view of applicant's submission of 
replacement sheets for figures 31, 32A, and 32B. 

3. The objections to claims 14-17 are withdrawn in view of applicant's amendments. 

4. The rejection under 35 U.S.C. 1 12, second paragraph, to claim 19 is withdrawn in view 
of applicant's amendment. 

5. Claims 3, 8, 10 and 13 have been cancelled. 

6. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are pending. 

7. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 stand finally rejected under 35 U.S.C. 102(b) as 
being anticipated by Mason (U.S. 5,668,998). 

Response to Amendment 
Claim Rejections - 35 USC § 102 

8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

9. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Mason (U.S. 5,668,998). 



Per Claim 1 (Amended): 
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The Mason patent discloses: 

- a method for constructing a service providing system using a framework for service 
providing system which provides a service for an object system ("A framework of service 
objects is provided which enables a programmer to easily develop application methods which 
provide DICOM services or other custom services. An object-oriented application interface is 
provided. The objects provide a map between DICOM standard service objects and a group of 
associated objects within a framework. The associated service objects work together to provide 
a DICOM service. The service objects comprise a method or a computer program which 
operates in conformance with the DICOM standard." in column 1, lines 10-19 and column 1, 
lines 66-67 to column 2, lines 1-2) 

- preparing a framework for service providing system, which includes a data holding part 
for holding data relating to an object system for which a service providing system 
constructed by said framework provides a service ("The present invention provides a 
framework of service interface objects which map onto a service described in the DICOM 
standard. Each service interface object, when instantiated, is uniquely associated with a user 
handler and a provider handler ... An implemented DICOM service, or set of objects which 
implement the DICOM service, is placed in the framework of objects. The DICOM service 
collection of objects is then available to an application programmer accessing the framework in 
implementing the same or a similar DICOM service." in column 2, lines 3-7 and column 7, lines 
43-48; the DICOM service collection of objects is interpreted as a data holding part) 
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- a user interface part for receiving instructions from a user and for presenting data to the 
user when the user employs the constructed service providing system ("Turning now to Fig. 
2, in a example of an operational scenario, a DTServicelnterface object 1 1 initiates a request. 
This is true for all service classes. The only difference between a verify request and one of the 
print requests is the particular subclass of the DTServicelnterface object that is chosen by the 
application developer. The outgoing message is called a "Request". . . . The incoming message is 
called a "Confirmation". ... At this point in time, the confirmation has been received, so the 
transaction is considered complete. It is the responsibility of the DTServicelnterface object to 
look at the status that was returned. If the status was success, the DTServicelnterface object may 
be cleaned up. If the status was not success, it is the responsibility of the application developer 
to determine how to recover from a bad status. Any of these actions could cause the application 
developer to need to create a subclass of the appropriate DTServicelnterface class." in column 7> 
lines 64-67 to column 8, lines 1-3; column 8, lines 56-67 to column 9, lines 1-18; for example, 
see Fig. 2, "API", on the SCU side) 

- an object system interface part for exchanging data between the object system interface 
part and said object system in accordance with a predetermined protocol ("In the present 
invention, DICOM standard services are implemented by objects or o methods which exist 
within a toolkit framework. In a preferred embodiment, the framework is divided into 
application subsystems and internal subsystems. . . . Application subsystems provide a 
framework of objects mapped to an abstract form of DICOM services. The application 



Application/Control Number: 09/66 1,916 Page 5 

Art Unit: 2124 

framework and associated mapping to DICOM services provides an application interface to the 
toolkit framework. The application interface simplifies creation of an application program which 
provides DICOM services and conforms to DICOM protocol" in column 7, lines 49-63; the 
application interface is interpreted as an object system interface part) 

- an integrated control part for controlling said data holding part, said user interface part 
and said object system interface part ("Handler objects (SCUs/SCPs) enable an application to 
send and return calls to and from other applications ... A SCU/SCP (service user handler/service 
provider handler) pair exists for each DICOM user service. The SCU, service user handler 
initiates a DICOM message service request. The SCP, service provider handler responds to the 
service request." in column 2, lines 43-50; Handler objects (SCUs/SCPs) are interpreted as an 
integrated control part for controlling the DICOM service collection of objects, API, and 
application interface, which are interpreted as data holding part, user interface part and object 
system interface part, respectively) 

- preparing a plurality of classes on the basis of each of said data holding part, said user 
interface part, said object system interface part and said integrated control part of said 
framework for service providing system; associating said classes with each other; and 
defining a sequence carried out between the respective classes wherein said object system 
interface part of said framework for service providing system converts external data, 
which are exchanged between said object system interface part and said object system, into 
a format of intermediate data which is independent of said protocol, and said integrated 
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control part of said framework for service providing system converts said intermediate 
data into a format of internal data which is handled in said service providing system, said 
data holding part and user interface part of said framework for service providing system 
handling said internal data which have been converted by said integrated control part 

("Each service is functionally distributed among atomic service units, each unit representing the 
smallest portion of a service provided by the present invention. Each atomic unit is represented 
by a base class, from which service objects are derived ... A base class for handler object is 
provided from which an application subclasses to generate handler objects. Sub-classing enables 
an application to customize the actions taken by a service interface object. . . . The outgoing 
message is called a "Request". The request is encoded 12 into a DICOM message. This 
involves two processes. First, the message is formulated into the DICOM Toolkit's own internal 
representation which we call an element list. Each individual attribute that together will 
compromise the message is represented in this list. The elements in the list then each in ram, 
dumped into packets specified by the DICOM protocol. The elements themselves, each know 
how to format themselves correctly. These packets are transmitted across a network 13 (ethernet, 
fddi, etc.) to a DICOM service provider. The incoming packets are decoded 14 by the service 
provider 15, and an element list that is identical to the one that was transmitted is created by the 
provider. The incoming message is called an "Indication". The decoding process determines the 
message type. This information is used to route the message to the correct DTProviderHandler." 
in column 57-67 to column 3, lines 1-4; column 8, lines 2-22). 



Per Claim 2: 
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The Mason patent discloses: 

- wherein said integrated control part of said framework for service providing system 
controls data which are held in said data holding part, and connects said data holding part 
with said user interface part to provide various services for said object system on the basis 
of data which are given from said user or said object system (column 2, lines 43-50 and 
column 2, lines 64-67 to column 3, lines 1-15). 

Per Claim 4: 

The Mason patent discloses: 

- wherein said service providing system is a monitoring system for monitoring an external 
apparatus serving as said object system (column 1, lines 27-29 and column 2, lines 13-15). 

Per Claim 5: 

The Mason patent discloses: 

- wherein said service providing system is a control system for controlling a controlled 
apparatus serving as said object system (column 1, lines 27-29 and column 2, lines 10-21). 



Per Claim 6: 

The Mason patent discloses: 
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- wherein said service providing system is an information system for exchanging 
information between the service providing system and an information system serving as 
said object system (column 2, lines 35-42). 

Per Claim 7 (Amended): 

This is a system version of the claimed method discussed above (claims 1 and 2), wherein 
all claim limitations also have been addressed and/or covered in cited areas as set forth above. 
Thus, accordingly, this claim is also anticipated by Mason. 

Per Claim 9 (Amended): 

This is a computer readable recording medium version of the claimed system discussed 
above, claim 7, wherein all claim limitations also have been addressed and/or covered in cited 
areas as set forth above. Thus, accordingly, this claim is also anticipated by Mason. 

Per Claim 11 (Amended): 

This is another version of the claimed computer readable recording medium discussed 
above, claim 9, wherein all claim limitations also have been addressed and/or covered in cited 
areas as set forth above. Thus, accordingly, this claim is also anticipated by Mason. 

Per Claim 12 (Amended): 
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This is a computer readable recording medium version of the claimed system discussed 
above, claim 7, wherein all claim limitations also have been addressed and/or covered in cited 
areas as set forth above. Thus, accordingly, this claim is also anticipated by Mason. 

Per Claim 14 (Amended): 

The Mason patent discloses: 

- wherein each of said data holding part, said object system interface part and said 
integrated control part includes a class which is prepared for every kind of object system, 
and said user interface part includes a class which is prepared for every kind of screens for 
interface (column 2, lines 57-67 to column 3, lines 1-15). 

Per Claim 15 (Amended): 

The Mason patent discloses: 

- wherein said class included in said data holding part is prepared for every kind of data, 
which are used in said object systems, in addition to the kind of said object systems (column 
2, lines 57-61). 



Per Claim 16 (Amended): 



The Mason patent discloses: 
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- wherein said class included in said integrated control part is prepared for every kind of 
services, which are provided for said object systems, in addition to the kind of said object 
systems (column 2, lines 64-67 to column 3, lines 1-4). 

Per Claim 17 (Amended): 

The Mason patent discloses: 

- wherein said class included in said integrated control part includes an upper class, which 
is prepared for every kind of said object systems, and a lower class which is prepared for 
every kind of services which are provided for said object systems under said upper class 

(column 2, lines 64-67 to column 3, lines 1-4). 

Per Claim 18: 

The Mason patent discloses: 

- wherein a class included in said integrated control part controls a class included in said 
data holding part (column 2, lines 43-50 and column 2, lines 57-67 to column 3, lines 1-4) 

- a class included in said user interface part updates and refers to said class included in said 
data holding part; data, which are given from said user and said object system, are 
exchanged between said class included in said user interface part and said class included in 
said integrated control part; and data, which relate to a service provided for said object 
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system, are exchanged between said class included in said integrated control part and said 
class included in said object system interface part (column 3, lines 5-15). 

Per Claim 19 (Amended): 

The Mason patent discloses: 

- wherein when service providing instructions for said object system are given to a class 
included in a user interface part, said class included in said user interface part reflects 
data, which relate to service providing instructions, in a class included in said data holding 
part, and gives a class included in said integrated control part notice of said service 
providing instructions (column 2, lines 35-50 and column 3, lines 5-15) 

- said class included in said integrated control part acquires data of said class included in 
said data holding part, and transmits data of said class, which is included in said data 
holding part, to a class included in said object system interface part, said class included in 
said object system interface part adding data, which relate to a protocol, to data received 
from said integrated control part (column 2, lines 64-67 to column 3, lines 1-4). 

Per Claim 20: 



The Mason patent discloses: 
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- wherein when service provided results from said object system are given to a class 
included in an object system interface part, said class included in said object system 
interface part deletes data, which relate to a protocol, from data received from said object 
system (column 8, lines 14-22) 

- and gives a class, which is included in said integrated control part, notice of service 
provided results, said class included in said integrated control part reflecting data, which 
relate to service provided results, in a class included in said data holding part, and giving a 
class, which is included in said user interface, notice of service provided results, and said 
class included in said user interface part acquiring data, which relate to service provided 
results, from said class included in said data holding part (column 8, lines 34-67 to column 9, 
lines 1-18). 

Response to Arguments 

10. Applicant's arguments with respect to claims 1-2, 4-7, 9, 11-12 and 14-20 have been fully 
considered but they are not persuasive. 
In the remarks, the applicant argues that: 

a) In contrast with Claims 1, 7, 9, 11, and 12, the API toolkit framework of Mason is merely 
an interface through which an application programmer customizes individual objects in the 
framework or alters parameter values and object behavior when developing the framework. 
Mason's API toolkit framework does not suggest or disclose the user interface part, as recited in 



Application/Control Number: 09/66 1,916 Page 1 3 

Art Unit: 2124 

Claim 1 , for example, which receives instructions from a user and presents data to the user when 
the user employs the constructed service providing system 

Examiner 's response: 

a) Examiner strongly disagrees with applicant's assertion that Mason fails to disclose the 
claimed limitations recited in amended claim 1 . Mason clearly shows each and every limitation 
in amended claim 1 . Mason teaches a user interface part for receiving instructions from a user 
and for presenting data to the user when the user employs the constructed service providing 
system (column 7, lines 64-67 to column 8, lines 1-3; column 8, lines 56-67 to column 9, lines 1- 
18; for example, see Fig. 2, "API", on the SCU side). In addition, see the rejection above in 
paragraph 9 for rejection to amended claim 1 . 

In the remarks, the applicant argues that: 

b) In addition, the handler object (SCP/SCU) of Mason does not correspond to either of the 
integrated control part or the object system interface part, as recited in Claim 1, for example. 
Specifically, the handler object (SCP/SCU) of Mason is merely used for transferring the 
messages in DICOM standard. Consequently, Mason's handler object does not teach, suggest, or 
disclose the integrated control part, as recited in Claim 1, which controls the data holding part, 
the user interface part, and the object system interface part. 



Examiner 's response: 
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b) Examiner strongly disagrees with applicant's assertion that Mason fails to disclose the 
claimed limitations recited in amended claim 1 . Mason clearly shows each and every limitation 
in amended claim 1 . Mason teaches an integrated control part for controlling said data holding 
part, said user interface part and said object system interface part (column 2, lines 43-50; 
Handler objects (SCUs/SCPs) are interpreted as an integrated control part for controlling the 
DICOM service collection of objects, API, and application interface, which are interpreted as 
data holding part, user interface part and object system interface part, respectively). In addition, 
see the rejection above in paragraph 9 for rejection to amended claim 1 . 

In the remarks, the applicant argues that: 

c) Furthermore, as shown in Fig. 2 of Mason, the handler object (SCP/SCU) (15, 19) merely 
decodes the message (see 14, 18) that comes from the service interface object (11, 16) of another 
application and does not carry out encoding of the message. As also shown in Fig. 2 of Mason, 
encoding of the message is carried out in the service interface object (11, 16). 

Moreover, in Mason, for example, exchanging data between applications is carried out by 
two different objects, the service interface object (11, 16) and the handler object (SCP/SCU) (15, 
19). In contrast, the invention as recited in Claim 1 exchanges data between the service providing 
system and the object system only one part, for example, the object system interface part, 
independently of other parts, for example, the data holding part, the user interface part, and the 
object system interface part. 

Also, as stated above, the encoding and decoding of the message are carried out in the 
separate objects, for example, the service interface object (11, 16) and the handler object 
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(SCP/SCU) in the framework of Mason. Therefore, Mason does not disclose or suggest the 
present invention, as recited in Claim 1, because, for example, Mason does not disclose or 
suggest that encoding and decoding may be carried out in the object system interface part 
independent of other parts, for example, the data holding part, the user interface part, and the 
object system interface part. 

In short, Mason would not have led to the invention, as recited in Claims 1, 7, 9, 11, and 
12 because Mason at least does not disclose or suggest the above referenced recitations of 
independent Claims 1, 7, 9, 11, and 12. Accordingly, independent Claims 1, 7, 9, 11, and 12 
patentably distinguish the present invention over the cited art, and Applicant respectfully 
requests withdrawal of the rejection of Claims 1, 7, 9, 11, and 12. 

Examiner } s response: 

c) Examiner strongly disagrees with applicant's assertion that Mason fails to disclose the 
claimed limitations recited in amended claim 1 . Mason clearly shows each and every limitation 
in amended claim 1 . Mason teaches an object system interface part for exchanging data between 
the object system interface part and said object system in accordance with a predetermined 
protocol (column 7, lines 49-63; the Examiner would like to point out that the application 
interface is interpreted as an object system interface part, which is only one part, independent of 
the other parts). In addition, see the rejection above in paragraph 9 for rejection to claims 1, 7, 9, 
11, and 12. 



In the remarks, the applicant argues that: 
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d) Dependent Claims 2, 4-6, and 14-20 are also allowable at least for the reasons above 
regarding independent Claims 1 and 12 and by virtue of their respective dependencies upon 
independent Claims 1 and 12. Accordingly, Applicant respectfully requests withdrawal of this 
rejection of dependent Claims 2, 4-6, and 14-20. 

Examiner 's response: 

d) The Examiner has already addressed the applicant's arguments regarding independent 
claims 1, 7, 9, 11, and 12 in the Examiner's Responses (a)-(c) above. In addition, see the 
rejection above in paragraph 9 for rejection to claims 2, 4-6, and 14-20. 

Conclusion 

1 1 . THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1. 136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1. 136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 
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12. Any inquiry concerning this communication from the examiner should be directed to 
Qarnrun Nahar whose telephone number is (703) 305-7699. The examiner can normally be 
reached on Mondays through Thursdays from 9:00 AM to 6:30 PM. The examiner can also be 
reached on alternate Fridays . 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki, can be reached on (703) 305-9662. The fax phone number for the 
organization where this application or processing is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703) 305-3900. 



QN 

October 16, 2003 




